Working Code Isn't Enough

「動くだけのコードは十分でない」

結果としてできるだけ早くタスクを終わらせようとする

そのため、より良い設計を求めることはしない

より複雑さは増加していく

気がついたらその複雑さを一掃するには数ヶ月の作業が必要となる

後回しにして、目先の機能実装を優先する

組織に少なくとも一人はいる

他の人よりもはるかに速くコードを書き、機能を実装する

そのため、経営陣からは英雄視される

一方、（Tactical Tornadoの書いたコードに触れる）エンジニアから英雄視されることは無い

目先の仕事を早く終わらせるためだけに、不必要な複雑さを導入すべきではない

「動くコード」を第一の目標と考えるべきではない

動作するだけでなく、優れた設計を生み出す

プロジェクトを終わらせる最速の道を選択するではなく、システムの設計を改善するために時間を投資する

https://scrapbox.io/files/658012ae85a83300234374c3.png

e.g. 新しいクラスを追加する

いくつか代替案を考えて、将来変更しやすいものを選択する

e.g. 分かりやすいドキュメントを書く

時間が経てば、間違いは浮き彫りになる

継続的なリファクタリング ∈ 継続的な設計

将来問題を引き起こす複雑な部分を少しずつ加える

具体的には、総開発時間の 10% ~ 20% 程度

しかしながら、その分良い設計が生み出され、数カ月後にメリットを実感する

成功すれば追加のエンジニアを雇う資金が手に入ると考え合理化する

酷いコードだとその噂が広まり、採用が難しくなる

システム構造が更に劣化する

どちらの選択をとっても成功することは可能であり、前例もある

新人エンジニアであっても入社1週間目には本番環境にコミットするのが普通

エンジニアに大きな裁量があり、評判となった

最終的にはエンジニアに優れた設計にもっと投資することを奨励

hr.icon

要約

先延ばしにすればするほど、問題は大きくなり、収集がつかなくなる